Each class member will be on a game development group as well as a technology study team. The game development groups are typically between 5-7 members. These will be decided during the first week of class. You are free to recuit members to your team. I will aid in assigning members to balance the distribution. The technology teams will cut across all of the game groups. Each class member will be responsible for their group's game development and for their group's assignments (see below). Several presentations will be required throughout the semester, including:
Communication is the key element to success. Your group needs to find a way to communicate effectively as soon as possible. There is no substitute for face-to-face communication -- you are strongly encouraged to establish a schedule where you are (almost) all together in one room for a few hours of dev time multiple times per week.
Try to make some progress every day. You have 14 weeks. That's not much time to build a game, but it's too long a time to try to work on this project as you might on a 2-week project. Slow-and-steady will beat bursts of activity in the long run.
Explore your recognizable risks first. Your recognizable risks are those things you know you don't yet understand. These could be elements of game play - will they be fun? They may also be elements of development - can I import the characters/animations the art team is building? Whatever you're not sure of, get to it as early as possible. Build the minimal functionality that is consistent with the long-term goal and that eliminates the risk - tells you what you need to know to be confident you can complete the final product.
Do it once. You don't have enough time to build anything multiple times. Try to get it right the first time. This means you have to design and test well enough that a component actually works, and does the right thing, the first time. You'll make much more progress slowly building an assemblege of reliable, appropriate components than you will quickly building a morass.
Set frequent milestones. A schedule (milestones) does two things for you. First, it's hard to work to a vague goal - the more concrete the goal, the easier it is to be motivated. Second, you can't know when you're behind, or how to adjust, if you don't have a schedule.
Prioritize. It's easy to let yourself work on the coolest thing, rather than the most important. Try to keep that to a minimum. Also, it's easy to work on some one thing past the point where it remains the highest priority item. Avoid that as well.
Integrate early. Integration, getting all the components (like the clients and server) to talk to each other, is the critical milestone. Pre-integration you'll be working on independent components that eventually must talk to each other. Even with great team communication it's likely that some incompatibilities will be found. These are very dangerous - work them out early. Additionally, pre-integration you don't have a game. Post-integration, you do, even if all it is is boxes moving around in a simple world. Once you've achieved integration, development becomes a lot easier. You'll basically be improving a game, piece by piece. It's much simpler to work independently, and so to get a lot more done by having everyone working at full capacity.
Corollary: Minimize your schedule risk by integrating early. You can't be sure how far in your design you'll actually get in 14 weeks. Schedule in a way that you have something presentable early, then work to improve it as much as you can.
Don't do this: The most ineffective schedule, proven by history, is to (a) not attack the hard parts (the risks) early, and (b) not test components as you build them, so that (c) you end up spending 11 weeks repeatedly debugging the things you didn't do right the first 3 weeks.
If you don't know it's broke, don't fix it. It's pretty common for teams to invest time early on addressing imagined performance problems with some complicated design. Don't. Your guesses about what will be and what won't be a performance issue are probably wrong, and in any case you don't have time work on imagined problems when there are so many actual ones floating around.
Write logs. Games are hard to debug in part because no execution sequence can be (easily) repeated. Log files aren't a panacea, but they'll help.
Working in teams is hard. If you're very lucky, someone on your team will be a gifted facilitator - someone who spends time (and is good at) making sure everyone is getting along and making progress, and that the team as a whole is communicating. A facilitator is an extremely valuable team role; you're sure to have plenty of people who can code, but it's not certain who, if anyone, will be able to assume any kind of leadership position.It's common for people to become frustrated with each other. The first four times you think to yourself "Harry is lame" the problem most likely lies with you, not Harry. Whatever you're contributing is going to be most valuable if it's surrounded by things other people have contributed, and so it's to your benefit to make sure Harry is contributing. As a team, you should find something for each person to do that (a) they want to do, and (b) they can do. Everyone has skills the others don't.
Make your best attempt to help Harry contribute. When you've done that four times and you're still thinking he's lame, there's a real problem. It may be that some other person on your team needs to handle it, or it may be that the course staff have to handle it. Coming to the staff is not turning someone in, it's just letting us know that there's some kind of problem. We promise to use our own highly fallible judgement coming to any conclusion about what the problem might be.
It is critical that you are sensitive to the role of ownership in team work. There is an ownership hierarchy. The entire class is one large team with joint, but loose, ownership of everything. There is no such thing as cheating in this class - help each other out. An individual team (dev plus associated art team members) owns the final product. It is crucial that everyone be allowed to contribute to what that product becomes. No one is going to work hard on anything that they have no influence on (and you can't afford as a team to have anyone not working). Finally, each person on the team needs to have some identifiable role that they own, and that is their responsibility. When you're done, everyone should have had some role they're proud of.
How to best organize varies from team to team, depending on the personalities and skills. At teams of this size, it is impractical to try to do everything as a group of equals. Different people should soon have different responsibilities. Your group may decide that someone will act as the big cheese - when disagreements arise, that person will make a final decision. That's okay, it isn't a violation of any ethic. At the same time, the big cheese has to be careful not to take themselves too seriously.
For this course you are permitted to make use of shared assets we've purchased in previous semesters. If after finishing this course you want to publish your game outside of OSU, then you will need to purchase whichever assets you've used. To find them: on the CSE 5912 Game Design and Development MSTeam, navigate to the "General" Channel, then select "Files" from the options on the top of that channel. Sometimes the assets will not natively work with the newest version of Unity, so if you come across any you'd like to use that aren't working, contact your instructor so that we can update that asset.